HARDWARE CONTROLLER AND MONITOR 



Technical Field 

[0001] The present invention relates generally to the field of electronics and, in 
particular, to the control and management of transport hardware. 

Background 

[0002] With the introduction of high-speed voice and data transmission the demand 
for management of transport hardware within telecommunications systems has 
significantly increased. As programmers work to reduce overhead, increase memory and 
increase the functionality of system operations line cards associated with the 
telecommunication systems have become more and more complex. Currently when a 
change to a particular piece of hardware on or associated with a line card is required a 
function on one of many modules on the board interrogates all of the different pieces of 
configuration. The function determines whether or not things have changed in the 
hardware and whether or not things in the hardware need to be changed. The function 
then proceeds to reconfigure all pieces of the system. These operations are not only 
inefficient but require a significant amount of overhead and memory. 

[0003] For the reasons stated above, and for other reasons stated below which will 
become apparent to those skilled in the art upon reading and understanding the present 
specification, there is a need in the art for improvements in the management of transport 
hardware in telecommunications systems and various types of hardware in other systems. 

Summary 

[0004] The above mentioned problems with the management of hardware in systems 
such as telecommunications systems and other problems are addressed by embodiments 
of the present invention and will be understood by reading and studying the following 
specification. 
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[0005] In one embodiment, a transmission system is provided. The system includes a 
hardware monitor adapted to collect performance information about associated hardware 
components, a system information database adapted to refresh based on the collected 
performance information and to generate system status information, and a hardware 
controller adapted to selectively communicate alarm change messages to one or more of 
the hardware components based on the collected performance information and the system 
status information. 

[0006] In one embodiment, a local transmission system is provided. The system 
includes a detection device adapted to identify alarm information within the local 
transmission system and to identify received alarm information from one or more 
associated remote units and a system information database adapted to store system status 
information and to refresh based on alarm information identified by the detection device. 
The system further includes a hardware controller adapted to selectively communicate 
alarm change messages to one or more hardware components based on the alarm 
information and the system status information. 

[0007] In one embodiment, a method of hardware management is provided. The 
method includes receiving notification of a change in alarm state from a remote unit of a 
transmission system, storing the change in alarm state information in a system 
information database, and distributing an alarm change message to a hardware controller. 
The method further includes receiving the alarm change message and querying the 
database as to which state the alarm is in currently, and changing the current hardware 
configuration via associated hardware drivers. 

[0008] In another embodiment, a method of hardware management for a transmission 
system is provided. The method includes detecting an alarm indication, performing 
information calculations on the alarm indication, and refreshing an associated system 
information database with the information calculations and the alarm indication. The 
method further includes distributing an alarm change message to a hardware controller 
and a notification device, receiving the alarm change message and determining the 
hardware to be changed based on the alarm change message and the current state of the 
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associated alarm, and requesting a change to the current configuration of hardware via 
hardware drivers. 

Brief Description of the Drawings 

[0009] Figure 1 is a block diagram of one embodiment of a system for controlling and 
monitoring hardware in a transmission system according to the teachings of this invention 

[0010] Figure 2 is block diagram of one embodiment of a system including a 
hardware controller according to the teachings of the present invention. 

[0011] Figure 3 is a flow chart of one embodiment of a method of hardware 
management for a transmission system according to the teachings of the present 
invention. 

[0012] Figure 4 is a flow chart of another embodiment of a method of hardware 
management for a transmission system according to the teachings of the present 
invention. 

Detailed Description 
[0013] In the following detailed description, reference is made to the accompanying 
drawings that form a part hereof, and in which is shown by way of illustration specific 
illustrative embodiments in which the invention may be practiced. These embodiments 
are described in sufficient detail to enable those skilled in the art to practice the invention, 
and it is to be understood that other embodiments may be utilized and that logical, 
mechanical and electrical changes may be made without departing from the spirit and 
scope of the present invention. The following detailed description is, therefore, not to be 
taken in a limiting sense. 

[0014] Embodiments of the present invention provide a system and method that acts 
as a governing body over hardware in a transmission system. The system and method is 
implemented in various parts and system levels (e.g. software, firmware, hardware and 
the like) to include a hardware controller and a hardware monitor. The hardware 
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controller reacts to alarms from hardware. The hardware monitor collects performance 
information about the hardware. In one embodiment, the hardware controller and the 
hardware monitor comprise a module. The module acts as an interface between an 
associated database and the hardware. In one embodiment, the module provides a 
transport hardware controller and a transport hardware monitor for a telecommunications 
transmission system (e.g. DSL, HDSL, xDSL line cards or the like). In one embodiment, 
the transmission system design complies with the G.SHDSL requirements for the 
transmission and multiplexing of data over a single pair of wires. 

[0015] Embodiments of the present invention provide a monitoring and control 
system for hardware that is expandable, flexible and modular. It allows the expansion in 
the number of hardware ports that can be implemented with ease. For example to expand 
from one digital subscriber line port to two digital subscriber line ports all that is required 
is a change to an identification number in the program. The system updates with two 
digital subscriber line ports and operates from there. The number of controllers within a 
system is expandable by simply attaching additional controllers. The additional 
controllers communicate their existence and the system configures operation with the 
additional controllers. 

[0016] Figure 1 is a block diagram of one embodiment of a system for controlling and 
monitoring hardware in a transmission system, shown generally at 100, according to the 
teachings of this invention. System 100 includes a system information (SI) database 124 
coupled between a hardware monitor 130 and a hardware controller 120. Hardware 
controller 120 is adapted to communicate with one or more hardware drivers 112-1 to 
112-N. 

[0017] In one embodiment, hardware controller 120 and hardware monitor 130 
comprise a hardware module 150. Module 150 is the governing body over the system 
hardware (e.g. El, DSL, Dataport). Hardware controller 120 reacts to alarms from the 
associated hardware and hardware monitor 130 collects performance information about 
the associated hardware. Module 150 is the interface between SI database 124 and any 
associated hardware. In one embodiment, the associated hardware comprises transport 
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hardware such as El/Tl port, digital subscriber line port, serial dataport, or the like. In 
another embodiment, the associated hardware further includes light emitting diode port, 
power feed control, or the like. 

[0018] Module 150 is adapted to operate with various types of transmission systems 
having one or more application modes. For example a telecommunications transmission 
system (e.g. providing DSL, HDSL, xDSL) consisting of a line card providing one or 
more of El, DSL, serial data transmission, or the like. 

[0019] Hardware monitor 130 is implemented as a task responsible for periodically 
checking the various hardware components for state changes. In one embodiment, 
hardware monitor 130 checks for alarms or error counts and keeps the unit's SI database 
124 refreshed. In one embodiment, SI database 124 accumulates each of the error counts 
for a 24 hour and 7 day history and the alarms are recorded as first and last occurrence. In 
other embodiments, SI database 124 accumulates error counts and records alarms based 
on user requirements. In one embodiment, hardware monitor 130 calculates performance 
statistics and generates alarms for each of the ports in the system. Hardware monitor 130 
is programmable to provide statistics and information about system operations as well as 
generate signals based on user requirements. 

[0020] In operation, transport hardware controller 120 is responsible for reacting to 
changes that occur in SI database 124. Transport hardware controller 120 reacts to 
various alarms (remote loss of signal (RLOS), loss of sync word (LOSW), power feed 
short (PFS), and the like.) Transport hardware controller 120 causes changes to 
associated hardware based upon a change in SI database 124 using appropriate hardware 
driver(s) 112-1 to 112-N. 

[0021] Transport hardware monitor 130 and transport hardware controller 120 work 
closely together to make a system such as a transmission system work. In one 
embodiment, they are not implemented in the same task and there is not direct connection 
between hardware monitor 130 and hardware controller 120. Transport hardware monitor 
130 and transport hardware controller 120 use SI database 124 to facilitate 
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communication between them. For example when the hardware needs to react to alarm 
events, SI database 124 is updated with the new alarm indications and the associated 
hardware changes its current configuration. 

[0022] Transport hardware monitor 130 is implemented as a group of periodic events. 
Transport hardware monitor 130 queries various hardware components (e.g. drivers 1 12- 
1 to 1 12-N) for the current status. 

[0023] In current systems, the hardware controller has to poll the database for changes 
in configuration. Embodiments of the present invention include hardware monitor 130 
that monitors the hardware and refreshes SI database 124 which in turn send messages to 
the hardware controller 120 indicating current alarms and/or detected errors in the system. 
As a result the amount of overhead required to manage the hardware in a system is 
significantly reduced. In addition, having hardware management implemented in 
multiple defined parts to include the hardware monitor 130 and hardware controller 120 
which interface via SI database 124 makes management of hardware in the system easier 
to understand. 

[0024] In one embodiment, system 100 further includes a notification device 160 
adapted to transmit collected performance information and system status information to 
one or more associated remote units. In another embodiment, system 100 further includes 
detection device 165 adapted to identify alarm information received from one or more 
associated remote units. In one embodiment, notification device 160 is an embedded 
operations channel. In one embodiment, detection device 165 is an embedded operations 
channel. 

[0025] Figure 2 is one embodiment of a block diagram of a system, shown generally 
at 200, including a hardware controller according to the teachings of the present 
invention. System 200 includes a system information database 224 coupled to a hardware 
controller 220. Hardware controller 220 includes a change response generator 240 
coupled to one or more hardware port controllers 250-1 to 250-X. Hardware port 
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controllers 250-1 to 250-X communicate with port drivers 212-1 to 212- Y via application 
interface (API) 260. 

[0026] In operation, hardware controller 220 is implemented as a task which pends on 
message queue 244. SI database 224 determines that an element in database 224 has 
changed and notifies hardware controller 220. Message queue 244 collects messages that 
are received from SI database 224 regarding which part of database 224 has changed so 
that associated hardware can be changed accordingly. SI database 224 also insures that 
multiple instances of the same message do not get posted to hardware controller 220. For 
example, SI database 224 receives information from one or more devices that monitor 
alarms and determine the status of associated hardware. SI database 224 compares the 
received information to the current information stored in SI database 224 and provides 
messages to hardware controller 220 only when a change in an associated hardware has 
occurred. In one embodiment, message queue 244 is the single interface into hardware 
controller 220. When a message is posted to message queue 244, the user causes 
hardware controller 220 to execute. In one embodiment, SI database 224 is the only 
module that can post messages to hardware controller 220. 

[0027] Many different messages can be posted to message queue 244. Each of the 
messages notify hardware controller 220 that a change in an associated system has 
occurred. In one embodiment, there are two types of messages: 

[0028] 1 . Notification of a change in state of an alarm; and 

[0029] 2. Notification of a change in configuration. 

[0030] Each of these messages is posted to the same message queue 244 to be 
processed by hardware controller 220. In one embodiment, messages sent by SI database 
224 to hardware controller 220 consist of a database element identification (ID ) of the 
configuration object that has changed or the specific alarm ID that has changed state, 
along with the location of the change. In one embodiment, where system 200 operates to 
control transport hardware in a telecommunications system the location of the change 
would be a local or remote unit. Table 1 below includes a list of possible messages for 
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alarm notification for one embodiment of a telecommunications transmission system 
supporting El/Tl and/or serial data over DSL, Table 2 below includes a list of possible 
messages for configuration notification for one embodiment of a telecommunications 
transmission system supporting El/Tl and/or serial data over DSL. 



Table 1 - Alarm Notification Messages 



Alarm Notify Message 


Description . I 


SI_El_ALARM_VECTORJD 


Indicates a change in state of any El alarm. 


SI El LOS ALM ID 


Indicates a change in state in a Local Loss of Signal alarm (El). 


SIJE1JLFA__ALM_ID 


Indicates a change in state in a Loss of Frame Alignment alarm (El). 


SI JE 1 _RALALM_ID 


Indicates a change in state in a Remote Alarm Indication alarm (El). 


SI El AIS ALM ID 


Indicates a change in state in an Alarm Indication Signal alarm (El). 


SI N64K ALARM VECTOR ID 


Indicates a change in state of any dataport alarm. 


SI N64K LOC ALM ID 


Indicates a change in state in a Loss of Clock alarm. 


SI_E1_LAST_24HRJD 


Indicates the detection of an ES on the application port (El). 


SI DSL LINK STATUS ID 


Indicates a change in state of the DSL loop status (DSL). 


SI DSL ALARM VECTOR ID 


Indicates a change in state of any DSL alarm. 


SI DSL LOSW ALM ID 


Indicates a change in state in a Loss of Sync Word alarm (DSL). 


SI DSL MAR ALM ID 


Indicates a change in state in a Margin alarm (DSL). 


SI_DSL_ES_ALM_ID 


Indicates a change in state in an Errored Second Threshold alarm (DSL). 


SI_DSL_LA_ALM_ID 


Indicates a change in state in the Loop Attenuation alarm (DSL). 


SI DSL PFS ALM ID 


Indicates a change in state in a Power Feed Short alarm. 


SI_DSLJLAST_24HR_ID 


Indicates the detection of an ES on the DSL port (DSL). 


SI CHANNEL STATUS ID 


Indicates a change in the channel's status. 


SI_LOOP_REV_ID 


Indicates the loops of a system are reversed. 


SI CLK STATE ID 


Indicates a change in the activity of each of the master clock sources. 



Table 2 - Configuration Notification Messages 



Confifi Notify Message 


Description _ .Ll.L;^:..!!:-;!:^:!: . : 


SI LPBK POS ID 


Indicates a change in loopback configuration (position, direction). 


SI_BERT_STATE_ID 


Indicates a change in bit error rate testing configuration. 


SI DSL LINE RATE ID 


Indicates a change in DSL rate (in number of timeslots). 


SI_PRIMARY_TIMING_ID 


Indicates a change in the primary timing source. 


SI BACKUP TIMING ID 


Indicates a change in the secondary timing source. 


SI_E1_NUM_TS_ID 
SI_E1_BEGIN_TS_ID 


Indicates a change in the timeslot assignment for the El port 


SI CRC4 MODE ID 


Indicates a change in the El port's CRC4 mode. 


SI CAS MODE ID 


Indicates a change in the El port's CAS mode. 


SI El IDLE CODE ID 


Indicates a change in the El port's idle code. 


SI_AIS_MODE_ID 


Indicates a change in the El port's AIS mode. 


SI_N64K_INTERFACE_ID 


Indicates a change in the N64K port's interface setting. 


SI_N64K_NUM_TS_ID 
SI_N64K_BEGIN_TS_ID 


Indicates a change in the timeslot assignment for the N64K port. 


SI N64K TX CLK ID 


Indicates a change in the TX clock selection. 


SI CTS CTRL ID 


Indicates a change in the CTS control selection. 
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SI_DSR_CTRLJD 


Indicates a change in the DSR control selection. 


SI RLSD CTRL ID 


Indicates a change in the RLSD control selection. 


SI LLRL CTRL ID 


Indicates a change in the LL/RL control selection. 



[0031] For example a message ID: SI_EUALARM_VECTOR_ID is an indicator of 
a change in state of any El alarm and controllers for El, Dataport, DSL and LED are 
notified. The purpose of this alarm is to update a transmission system at both a local and 
remote location on any change in the state of alarms. 

[0032] For example a message ID: SI_BERT_STATE JD configures the hardware to 
facilitate a bit error rate test. In this embodiment, controllers for El, Dataport and DSL 
are notified. As a result of this configuration notification the bit error rate testing portions 
of the hardware will be setup to facilitate testing, pseudo-random bit sequence generators 
will be started and mapped into the data stream, and meters will measure the number of 
bit errors during the test interval. 

[0033] Configuration changes occur from different sources in the associated 
transmission system. As the configuration changes, the hardware needs to be configured 
accordingly. These configurations are based upon information stored in SI database 224. 
SI database 224 notifies hardware controller 220 of a change in configuration. Hardware 
controller 220 is comprised of a change response generator 240 and a plurality of 
hardware port controllers 250-1 to 250-X. As change response generator 240 receives a 
message from SI database 224 it generates a response appropriate for the particular ports 
that it controls. Each hardware port controller 250-1 to 250-X then creates the 
appropriate hardware response based upon the received database information change. 
Each hardware port controller 250-1 to 250-X has a set of functions to control them. 

[0034] Change response generator 240 is responsible for creating a response to a 
configuration or alarm change on a port-by-port basis. This portion of hardware 
controller 220 takes a message from message queue 244 and generates an appropriate 
response for each of the attached port controllers 250-1 to 250-X. In one embodiment, 
when hardware controller 220 receives a remote loss of signal (RLOS) message, change 
response generator 240 will create and transmit port controller commands to El port 
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controller 250-1 and data port controller 250-2. El port controller 250-1 and data port 
controller 250-2 will then appropriately deal with the received port controller commands. 
Change response generator 240 includes a table to keep all of the port responses for each 
of the possible database messages. In one embodiment, upon startup, the table is filled 
with information pertaining to the detected ports and pointers to functions that will cause 
a particular response to the incoming event for the assigned port. 

[0035] In one embodiment, change response generator 240 includes an additional 
table to facilitate the sequencing of port responses. Depending on the message from SI 
database 224 change response generator 240 determines in which order to execute the 
responses for each of the associated ports. This table allows for each of the response 
sequences to have its own preset sequence. In one embodiment, a single port executes 
multiple responses for a single message. For example, it may be necessary to have El 
port controller 250-1 execute a portion of a response, then have DSL port controller 250-3 
execute a response, and El port controller 250-1 finish its response. 

[0036] Each port controller 250-1 to 250-X is responsible for determining whether or 
not to carry out commands received from change response generator 240. In one 
embodiment, LED port controller 250-5 controls various LED's of a telecommunications 
line unit. LED port controller 250-5 responds to various events that occur in the system. 
LED port controller 250-5 registers its responses with change response generator 240, on 
startup and change response generator 240 generates responses for LED port controller 
250-5. 

[0037] Figure 3 is a flow chart of one embodiment of a method of hardware 

management for a transmission system, shown generally at 300, according to the 
teachings of the present invention. The method begins at block 310 and detects an alarm 
indication. In one embodiment, detecting an alarm indication comprises periodically 
checking hardware components for state changes. In another embodiment, detecting an 
alarm indication comprises checking hardware components for hardware alarms and error 
counts. In a further embodiment, detecting an alarm indication comprises detecting one 
or more of remote loss of signal, loss of sync word, power feed short, or the like.. The 
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method proceeds to block 320 and performs information calculations on the alarm 
indication. In one embodiment, performing information calculations on the alarm 
indication includes calculating performance statistics and generating alarms for each of 
the ports in the transmission system based on user-defined requirements. 

[0038] At block 330 the method refreshes an associated system information database 
with the information calculations and the alarm indications. In one embodiment, 
refreshing an associated system information database with the information calculations 
and the alarm indication, includes passing the alarm indication and associated information 
calculations to the system information database, receiving the alarm indication and 
associated information calculations, and storing the current alarm indication and 
associated information calculation in one or more tables for subsequent retrieval. In one 
embodiment, storing the current alarm indication and associated information calculations 
comprises time stamping the current alarm indication. 

[0039] The method proceeds to block 340 and distributes an alarm change message to 
one or more of a hardware controller and a notification device. In one embodiment, 
distributing an alarm change message to a hardware controller comprises posting the 
alarm change message to a message queue. In one embodiment, posting the alarm change 
message to a message queue causes the hardware controller to execute and queries the 
database as to the current system status and determines which hardware to be changed. 
At block 350 the alarm change message is received and at block 360 the hardware to be 
changed is determined based on the alarm change message and the current state of the 
associated alarm. In one embodiment, the hardware to be changed includes how to 
operate the system based upon the current system conditions on a port-by-port basis. The 
method proceeds to block 370 and changes to the current configuration of hardware are 
requested via associated hardware drivers. 

[0040] In one embodiment, method 300 proceeds to block 380 and notifies one or 
more associated remote units of the change in alarm state. In another embodiment, 
method 300 includes accumulating error counts and recording alarm indications based on 
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user-defined requirements. In one embodiment, accumulating and recording is performed 
by SI database. 

[0041] Figure 4 is a flow chart of another method of hardware management for a 

transmission system, shown generally at 400, according to the teachings of the present 
invention. One or more remote units that have received notification of a change in alarm 
state execute method 400. At block 410, the method detects the change in alarm state. In 
one embodiment, detecting the change in alarm state includes detecting one or more of 
remote loss of signal, loss of sync word, power feed short, or the like. The method 
proceeds to block 420 and stores the change in alarm state information in a system 
information database. In one embodiment, storing the change in alarm state information 
comprises time stamping the current alarm indication. At block 430 the method 
distributes an alarm change message to a hardware controller and at block 440 the alarm 
change message is received. In one embodiment, the method posts the alarm change 
message to a message queue for processing. In one embodiment, posting the alarm 
change message causes the hardware controller to execute querying and changing the 
configuration. The method proceeds to block 450 and queries the database as to which 
state the alarm is in currently. At block 460 when required the current hardware 
configuration is changed via associated hardware drivers. 

[0042] In one embodiment, method 400 further includes accumulating error 

counts and recording alarm indications based on user-defined requirements. In one 
embodiment, this information is stored in the SI database. 
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